前幾天討論了 Rive 的優缺點，以及跟其他技術的比較。如果看完這些你決定用 Rive 的話，因為 Rive 必須要設計師們的配合，所以以下是就我們這兩年的實作經驗，整理出一些設計師需要的注意事項。這些事情如果設計師大大們願意做，那輸出的 .riv 檔會讓前端好做非常多，會讓整個團隊省下更多時間與開發成本這樣。

有意義且直覺的命名

命名這個概念可能對設計師比較陌生，但在用 Rive editor 的時候，常常會遇到需要命名的情況，例如檔案名稱、state machine、state machine input、event 等等。命名要盡可能的有意義且直覺，盡量描述內容物是什麼，盡量不要用預設的名字，滿足以上這些條件的話，命名要越短越好。

就我們的經驗來說，設計師跟這個星球上其他的正常人類一樣，不一定能理解為什麼命名對工程師來說這麼重要，只能說工程師要 case by case 多跟設計師大大們溝通，並且要有度過一段磨合期的心理準備，但通常設計師們最後也會慢慢理解，所以稍微留意一下這個問題就好。

區分元件邏輯與商業邏輯

Rive 其實比較像是在設計元件，就像 Bootstrap 那樣，前端工程師對元件的概念應該不陌生，但設計師不一定。就我的經驗來說，很多時候設計師做出來的東西會摻太多商業邏輯在裡面，會太過耦合，降低可復用性。

但跟上一個問題一樣，設計師不一定有這個概念，我以前會大概會多打三千個字跟你解釋說阿什麼是元件邏輯阿什麼是商業邏輯阿兩者差別在哪阿為什麼要低耦合高內聚阿巴阿巴阿巴阿巴阿巴，後來是覺得這種東西……看緣分啦。設計師通常比較善解人意，想法比較全面，所以他們看東西常常是從整體的角度去看，優點是如果設計師大大非常有經驗的話，他的設計就會兼顧到所有層面，其他跟他合作的人只要照著他的想法去做，絕對萬無一失，大家都很開心。所以某種程度上來說，在這個情境下耦合是好事，代表我神機妙算，把你的問題都考慮進去了，所以我的元件不只可以處理元件邏輯，還可以處理商業邏輯，很厲害吧。

工程師則是習慣把事情切開來看，橫著切縱著切，切成前端後端，前端再切成元件邏輯商業邏輯，還要每個 domain 切開來，最好再 micro service 一下，這樣就算哪一層或哪個服務爆炸了，只會燒到他自己，死貧道不死道友，大家平常用對外 API 溝通就好。這兩種想法誰對誰錯不好說，但無論最終採用哪一個，都需要一點時間磨合。

我只能說通常來說，Rive 其實有點像請設計師幫忙切版寫程式，如果設計師非常有經驗，那把邏輯寫在一起好像也沒什麼問題。如果不是的話，還是需要多溝通一下。有時候有點像北風跟太陽，直接溝通其實不一定有用，還是要多試幾次，case by case 多交流一下，人有趨吉避凶的本能嘛，通常幾次之後就會越來越理解了。所以看緣分這幾個字聽起來有點像幹話，但其實是真的。

區分大小寫跟空白

最後是一件小事情啦，在程式設計的世界中，大小寫是有差別的，例如 Button 跟 button 是兩個不一樣的東西。這聽起來可能有點荒謬，但兩邊溝通的時候，用字可能要精確一點，常常一方說我寫的 state machine 叫做 Button，結果 debug 半天後發現其實是 button。

空白鍵也是，可能設計師說一個 key 叫做 current state，結果抓到最後發現是 currentstate。這種小東西一多的話，其實會增加不少溝通成本，所以平常還是要注意一下。

這篇算是偏實務上會遇到的疑難雜症與心態問題，跟技術雖然沒有太大的關係，但反而比技術問題更影響開發進度，所以也趁這個機會做個紀錄。在一般的公司裡面，技術問題終究很少成為開發的瓶頸。